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ItEMARKS 

1. INTRODUCTION 

Applicant has amended claim 13. Accordingly, claims 1 - 36 remain pending and under 
consideration iii tliis application. Reconsideration and reexamination is hereby respectfully 
requested. 

2. CLAIM REJECTION UNDER 35 U.S.C. S IQl 

Claim 13 stands rejected under 35 U.S.C. § 101. In this regard the Office Action states 
that the recitation "performance of said metliod" constitutes an abstract idea. Applicant 
respectfully submits that the rejection has been overcome through amendment. 

Claims 16-25 stand rejected, and in this regard the Office Action states tiiat the claimed 
invention is directed to non-statutory subject matter. Apphcant respectfolly tiaverses the 
rejection. 

Applicant respectftdly directs the Examiner's attention to § 2106 of the MPEP Patentable 
Subject Matter - Computer-Related Inventions'. 

Computer programs are often recited as part of a claim. Office 
personnel should determine whether the computer program is 
being claimed as part of an otherwise statutory manufacture or 
machine. La such a case, the claims remains statutory irrespective 
of the fact that a computer program is included in the claim. The 
same result occurs when a computer program is used in a 
computerized process where the computer executes the instructions 
set forth in the computer program. Only when the invention taken 
as a whole is directed to a mere program listing, i.e., to only its 
description, is it descriptive material per se and hence non- 
statntory. 

Section IV(B)(l)(a), MPEP § 2106. 

Independent claim 16 recites "A method of detecting memory leaks for a program 

executing on a computer " Apphcant respectfully submits that the claim as a whole does not 

attempt to claim a program listing — ^the descriptive material. Rather, Claims 16-25 are directed 
to a statutory process, which statutory process ("A method of detecting memory leaks . . .") 
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Operates on the "program executing on a computer." Accordingly, pursuant to the MPEP, "only 
when the claimed invention talcen as a whole is directed to a mere progi-am listing, z.e., to only its 
description or expression, is it descriptive material per se and hence nonstatutory." AppHcant 
respectfully requests reconsideration and withdrawal of the rejection of claims 16-25. 

3. CLAIM REJECTION UNBER 35 U.S.C. S 102 

Claims 1-36 stand rejectedimder 35 U.S. C. § 102(e) as being anticipated by 
U.S. 2004/0078540 (Cime et al.). Applicant respectMly overcomes this rejection. 

Cime et oL Do Not Monitor Allocated Memory Levels 

As an initial matter, tlie Office has read the various recitations of "allocated memory 
levels" in the claims on the disclosures (in Cime et al.) involving tracking growth patterns of 
groups of stored items (e.g., one example is a Java collection). Applicant wishes to point out that 
while in general, an increase in the number of objects wiU correspond with an increase in 
memory consumption, this is not necessarily always true since there is not a direct relationship 
between objects and memory. In most implementations of object management, a block of 
memory is allocated and maybe used to store one object, multiple objects, or a variable number 
of objects. Accordingly, the claimed inventions involving "allocated memory levels" (as 
opposed to objects) are not only different and not disclosed by Cime et al, but are ratlier more 
complicated as well. This complexity arises because the allocation of objects in memory blocks 
creates an additional layer of abstractioiL The correlation between objects and memory worsens 
significantly beyond the simple situation of one-obj ect-per-memory block, for example, in the 
situations where there are multiple objects per memory block, the number of objects per block 
are growing, or the nmnber of objects per memory block are variable. Changes m the size (i.e., 
number) of objects do not necessarily alter allocated memory. 

In sum, Apphcant traverses the rejection of all claims 1-36 that are based on Cime et al. 
since Cime et al. at most teach tracldng the size of a group (of objects)— tlius an object leak 
methodology, and not a method and system of memory leak detection as claimed. 
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Moreover, while the Office has not made an obviousness rejection, Applicant, and. witli 
complete reservation of rights to address a specific obviousness rejection sliould it be made in 
the future, submit that the present invention is non-obvious in view of Cime et al. due to the 
distinctions between objects and allocated memory set forth above. 

Even assuming for the purpose of response only that "allocated memor}^' can be read on 
"object size" (which it cannot — see above), the claimed inventions nonetheless define novel and 
nonobvious subject matter, as explained m the remainder of tliis response, and accordingly 
should be allowed. 

Peak Allocated Memory Level 

Independent claims 1, 16 and 26 each recite "when a peak allocated memory level has 
increased a determined number of times." Ckne et al. do not teach or suggest this recitation. 

Cime et al. disclose technology tliat purports to identify potential sources of memory 
leaks by tracking growth patterns of groups of stored items. Paragi-aph [001 5] . "If the growtli 
pattern of a collection indicates that it may be the source of a memory leak, tiiat collection is 
reported to a user . . [0015]. Cime et al., however, do not provide a definition of what 
constitutes a "growth pattern." AppHcant has carefully reviewed Cime et al. and fmd only one 
discrete example of what is meant by "growth pattern." Li paragraph [0045] Cime et al. 
discloses that "[ajgent 8 looks for collection instances that appear to be constantly growing in 
size {i. e. , the number of objects stored in the collection grows)." Tlius, even assuming for the 
purposes of argument only that growth m the number objects stored corresponds to a growth in 
tlie memory used (see above), Cime et al. at most only disclose a gi owth pattern that is 
constantly growing in size. This approach does not meet the limitation of determining a "peak 
allocated memory level" and fiirther detennining when that pealc allocated memory level has 
increased a determined number of times, as positively claimed. 

For example, tlie teaching of Cime et al., namely, a growth pattern that is "constantly 
growuig in size" excludes the very example Applicant provided in its own Figure 3, paiticularly 
between peak P4 (time tj) and peak P5 (time te). Thus, wliile Applicant's process of monitoring 
for increases in the "peak allocated memory levels" wiU identify Figure 3, Cime et al.'s 
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"constantly growing in size" metliodology will fell to identify Applicant's Figure 3 as involving 
a memory leak because the allocated memory level is not "constantly growing" between ts and U 
but rather includes a decrease in between. In sum, Cime et al. simply do not teach identifying 
memory lealcs based on the specific approach involving "peak allocated memory levels." 

Accordingly, for at least this reason, Applicant respectfully requests reconsideration and 
wiUidrawal of tlie rejection of independent claims 1,16 and 26. 

Moreover, claims 2-15, 17-25 and 27-36 depend from claims 1, 16 and 26, respectively, 
and therefore include ail of the limitations thereof Accordingly, for at least flie same reasons. 
Applicant respectfully requests reconsideration and withdrawal of the rejection of these claims. 

Filtering Out Increases in Peak Allocated Memory Levels Not Indicative of a Memory 

Leak 

Moreover, independent claims 16 and 26 each recite "filtering out increases in peak 
allocated memory levels not indicative of a memory leak." Cime et al. does not teach or suggest 
this recitation. 

First, Cime et al. make no disclosure whatsoever of identifying, tracking and using a 
"peak allocated memory level" for any purpose, much less applying any filtering fimction to 
tliose peak levels where such peaks are not indicative of a memory leak. In this regard, the 
Office Action refers to paragraph [0017] of Cime et al. for the proposition that purports to meet 
this limitation: "reporting a flagged collection which no longer appears to be leaking." 
Applicant believes the Office is actually referring to paragraph [0016] for this proposition, which 
is reproduced below: "If a flagged collection no longer appears to be leaking, that change in 
status will be reported — " 

In any event, Cune et al. provide NO explanation whatsoever as to the underlying logic 
that caused its system to conclude that a collection is no longer leaking and certainly no 
explanation that the change in status from "LEAKING" to "NOT LEAKING" is tlie result of 
filtering out mcreases in peak allocated memory levels. This passage m Cime et al. describes a 
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simple reporting ftmction. Accordingly, Applicant respectfixlly submits that Cime et al. does not 
teach or suggest filtering increases in peak allocated memory levels not indicative of memory 
leak. This function is important since increases in the peak allocated memory levels not 
indicative of memory leak-that might otherwise trigger a memory leak condition-caa be 
suppressed (z.e., helpfiil in minimizing felse positives). 

Accordingly, for at least this reason. Applicant respectfully requests reconsideration and 
withdrawal of tlie rejection of independent claims 16 and 26. 

Additionally, claims 17-25 and 27-36 depend ftom clauns 16 and 26, respectively, and 
therefore include all of the limitations thereof Accordingly, for at least this additional reason, 
Applicant respectfully requests reconsideration and withdrawal of tlie rejection of these claims. 

Moreover, dependent claims 3 and 14 further include this recitation and is allowable for 
the same reason. 

lenorins Increases In Peak AUocated Memory Levels Purine A Startup Time Interval 

Claims 4, 14 and 28 positively recite tliat the "filtering step includes tlie substeps of: 
ignoring increases in peak allocated memory levels durimg a startup time interval immediately 
after said progi-am begins to execute . . .." Ciiiie et al. do not teach or suggest tliis feature. In 
tins regard, however, the OfBce has cited to paragraplis [0016] - [0017] of Cime et al. for the 
proposition that purports to satisfy this feature, namely, "discontinuing traek of newly allocated 
collections if no longer appear to be leaking." Applicant disagrees. 

Apphcant has carefully reviewed the cited paragraphs, and talces note of the disclosed 
time-out period. Applicant, however, points out that while tliis is a similai" term (the claimed 
"startup time" versus the disclosed "time-out period") the function is completely different, and 
in-fact is OPPOSITE. Cime et al. ONLY collects data during its "time-out period." On the 
contrary, however, according to the invention, data collection is EXCLUDED during its "startup 
time." This has the advantage in the present invention of disregarding potentially misleading 
memory allocations that occur when a program begins initial execution. In Cime et al., on the 
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oflier hand, the purpose of limiting downstream data collection after the "time-out period" is to 
reduce tlie overhead burden of the system (see [0017]). In Cime et al., if a monitored program 
does not immediately show a memory leak at the beginning of execution dming its "time-out 
period" it will fall off die monitored list. This is a significant shortcoming of Cune et al. relative 
to the present invention. 

Therefore, for at least tliese additional reasons, Applicant believes claims 4, 14 and 28 are 
allowable and respectfully requests reconsideration and withdrawal of the rejection. 

lenorine Increases In Peak Allocated Memory Levels That Occur After Said Startup 
Time Interval But That Occur Less Than A Preselected Time Apart 

Claims 5, 14 and 29 further recite that the "filtering step mcludes . . . ignoring increases 
m peak allocated memory levels that occur after said startup trnie interval but that occur less than 
a preselected time apart . . .." Cime et al. do not teach or suggest this recitation, ha tliis regard, 

however, the Office has cited to paragi-aph [0019] for the proposition tlrat purports to satisfy tliis 
feature, namely, "reclassifying stored group wliich appears not to be leaking." Applicant 
disagrees. 

Applicant has carefully reviewed flie cited paragraph, and takes note of tlie disclosure 
made in Cime et al. of a comparison between the current size of the group of objects being 
monitored and a tin-eshold, in order to reclassify tlie status of that group fi'om "leaking" to "not 
leaking." However, AppUcant find nothing in [0019] or anywhere else m Cime et al. tiiat deals 
with determining the time interval between peaks in allocated memory levels (as claimed, the 
"preselected time apart"), much less the function of ignoring an increase in a peak allocated 
memory level when it is less than a "preselected time apart" {i.e., measured relative to the 
previous "pealc" allocated memory level). This notion of a "peak-to-peak" tuner is not taught or 
suggested in Cime et al. Tliis feature is important since it allows the metiiod and system of the 
present invention to treat many increases in the peak allocated memory levels that are closely- 
spaced in time as a single event for leak detection purposes. This has a significant advantage in 
ehminating false alarms. 
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Therefore, for at least tliese additional reasons, Applicant believes claims 5, 14 and 29 are 
allowable and respectfully requests reconsideration and withdrawal of the rejection. 

Determinins a Memory Leakaee Rate 

hidependent claim 16 recites "determining a memoiy leakage rate — " Cirne et al. do 
not teach or suggest tliis hmitation. In this regard, however, the Office cites to paragraphs 
[0016] and [001 9] for the proposition that purports to satisfy this feature, namely, "tracking 
collection as metric data and reporthig the tracking of group of stored items reported as being a 
potential somce of a memory leak if the received size satisfies the cmxent value of a tiireshold." 
Applicant disagrees. 

Applicant has carefoUy reviewed the cited paragraphs and takes note that CuTie et al. at 
most disclose only a comparison between a collection size and threshold (size) {i.e., is the 
collection size greater than the threshold). The result of the comparison is a YES or a NO. In- 
fact, this "collection size" is measured in terms of a number "objects" and may not necessarily 
even correspond to allocated memory levels. Notwithstanding this, in sum, Cime et al. 
nonetheless make no disclosure of the relative amount by which the collection size exceeds the 
tiireshold, much less keep track of the series of such relative amounts as would be needed to 
determine a "memory leakage rate" (e.g., X kilobytes per minute, as specified in paragraph 
[0030] of Applicant's published ^pHcation under "S. MIN1MUM_RATE_F0R_ALARM"). 
Cime et al. cannot satisfy this limitation. 

Dependent claims 6-7, 15, 30-31 and 36 all include the recitation "memory leakage rate" 
which is respectfully submitted to lend an additional basis for patentability for the same reasons 
given above in comiection witli claim 16. 

In view of the foregoing, Applicant respectfully submits that the rejection of all of the 
claims has been overcome, and respectfully requests reconsideration and withdrawal of the same. 
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4. CONCLUSION 

For the foregoing reasons, all presently pending claims are now believed to be in a 
condition for allowance. Early notice of tlic same is hereby respectfuUy requested. 



^ectfully submitted. 



Date: Jmie 9, 2006 
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